Typically, in the interoperation of various networks, a user is challenged to provide access control information, such as user identification and password, by a system residing at the gateway between the two networks. In the event that a user is denied access to the next portion of the network, all of that user's packets can be discarded, or the user can be re-challenged to provide access control information. This scheme is common in the art. Although this authorization scheme does succeed in preventing unauthorized access it allows unauthorized traffic to fully traverse the first network before it is discarded. This generates unnecessary traffic which is transmitted over the first network consuming precious bandwidth.
Authorization for such schemes is provided through the use of systems like the Remote Authentication Dial-In User Service (RADIUS) protocol. RADIUS is a fully open protocol, distributed as source code, known in the art, which is a client/server system designed to prevent unauthorized access to networks. RADIUS clients run on network devices and send authentication requests to a central RADIUS server that contains both user authentication information and network access rights. RADIUS can be modified to work with any common security system. Common implementations for RADIUS include networks with multiple vendor access servers such as an Internet Protocol (IP) based network, where dial-in users can be authenticated through a RADIUS server customized to work with the KERBEROS security system, a common security system on-UNIX® like computer networks. Other common implementations include networks in which a user is permitted access to a particular service.
In this type of implementation a user could be restricted to a single utility, such as telnet, or a single server, or even a single protocol. This would permit RADIUS to identify a certain user as having access only to Point-to-Point-Protocol (PPP) using an IP address in a given range using only one service such as telnet or File Transfer Protocol (FTP).
RADIUS follows a client-server operational model. A Network Access Server (NAS), Remote Access Server (RAS), or the like, operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response that is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers.
RADIUS is carried in UDP (Port number 1812 decimal) and IP data units. At times, the source IP address field in client requests is zero since the client may not yet have an address, in which case the RADIUS system will allocate an address to the user from a pool of unused network addresses.
When a user attempts to login, the following steps occur to authenticate the user with RADIUS:    1. The user is prompted for and enters a username and password.    2. The username and encrypted password are sent over the network to the RADIUS server.    3. The user receives one of the following responses from the RADIUS server:            ACCEPT (The user is authenticated)        REJECT (The user is not authenticated and is prompted to re-enter the username and password, or access is denied)        CHALLENGE (A challenge is issued by the RADIUS server to collect additional data from the user)        CHANGE PASSWORD (A request is issued by the RADIUS server, asking the user to select a new password)        
RADIUS authentication must be performed before RADIUS authorization. The ACCEPT or REJECT response contains additional data that is used for EXEC or network authorization. The additional data included with the ACCEPT or REJECT packets consists of services that the user can access, including Telnet, rlogin, PPP, FTP, EXEC services, or connection parameters, including the host or client IP address, access list, and user timeouts.
User IP addresses can be statically provisioned or dynamically assigned using RADIUS or the like. In RADIUS, the ACCEPT or REJECT response contains the host or client IP address, access list, and user timeouts. Upon a user timeout, the user may be disconnected and if dynamically assigned, the IP address is returned to a pool of available addresses. BootP, DHCP, and TACACS+ can also be used to dynamically assign IP addresses to users but these protocols are less common than RADIUS.
Normally, a pool or group of addresses are pre-assigned by a network administrator and given out by the RADIUS server as users sign-on to the service provider. Typically used to oversubscribe IP addresses, a pool allows many clients to share a small number of IP addresses based on usage and contention patterns.
The Boot Protocol (BootP) is a UDP-serviced protocol that can be IP-routed to a BootP address server. Through the BootP protocol, the server can do many functions including IP address assignment, bootstrapping, operating system loading, desktop configuration, and hardware/interface configuration. BootP does not completely replace RADIUS as a subscriber management protocol. Dynamic Host Configuration Protocol (DHCP) is a newer alternative to BootP and possesses all the capabilities of BootP. As a rule, any BootP relay Agent (e.g., in a router or gateway) will work with DHCP. As with BootP, DHCP does not completely replace RADIUS as a subscriber management protocol.
An example of a known authentication scheme is depicted in FIG. 1. Here different User Networks 5 are connected to an Access Network 4, which in turn has a RADIUS clients at an egress edge. This RADIUS client 3 serves to ensure that only data with the correct authorization is allowed to go to the various ISP hosted networks 2a-2c. If a packet is not authorized it is discarded at the RADIUS client 3. To obtain the authorization, the RADIUS client 3 forms a connection to the RADIUS server 1 attached to the target ISP network which the packet is trying to enter. After forming this connection to the RADIUS server 1, the RADIUS client 3 can determine whether the user who initiated the packet transmission has authorization to transmit packets onto the target network. In such an implementation, the RADIUS client only controls access to the ISP hosted networks 2a-2c, while not controlling access to the Access Network 4, or between the User Networks 5. Thus, it is left to the administrators of the various User Networks 5 to ensure their own security and prevent admission of users from other User Networks 5 to systems to which those users should not have access.
Because data fully traverses the Access Network 4 before authorization is obtained, bandwidth on the Access Network 4 is needlessly consumed by transmissions that fail authentication. The unnecessary unauthorized traffic traversing the Access Network 4 can be problematic if there are restrictions on the available bandwidth, or if traffic is heavy. It would be desirable to stop this traffic as it enters the access network 4, so as to reduce loading problems. Moreover, the lack of centralized access control between the User Networks 5 is also undesirable.
One system addressing the problem of unnecessary traffic has been offered by CISCO Systems in the form of their Authentication, Authorization and Accounting (AAA) software. AAA acts to verify the authorization of a packet to enter an external network prior to entry of the packet into the access network. AAA also seeks to distribute the subscriber management features of the RADIUS client. Distributed subscriber management (DSM) provides a more fault tolerant implementation than a single RADIUS client does. However, in order to offer this service, a AAA client can only be attached to one User Network, since when multiple User Networks are connected to the same AAA client, one User Network, without challenge by the AAA system, could gain access to another User Network connected to the same AAA system. An example of an implementation known in the art and using AAA is found in FIG. 2. In that implementation, RADIUS Servers 1 are attached to ISP networks 2a-2c, a multitude of such networks are, in turn, connected to an Access Network 4. The Access Network 4 connects to a multitude of User Networks 5a-5c through AAA routed systems 6. Each User Network 5a-5c has its own AAA routed system 6 thus preventing one User Network 5a, 5b, or 5c from gaining access to another ISP User Network 5a, 5b, or 5c. The AAA system 6 is used to verify the authorization of the packets with the RADIUS Server 1, and will discard any user packets that do not have the correct authorization. Unfortunately this requires a different AAA system 6 for each ISP User Network 5a-5c that is connected to the Access Network 4, which can greatly add to the cost of a network.
Alternatives to RADIUS do exist, providing DSM systems with the option of implementing another type of security system. One of the alternatives to RADIUS is Terminal Access Controller Access Control System (TACACS). Three distinct versions of TACACS exist. The first is TACACS, which was the original product that provided password checking and authentication, as well as notification of user actions for security and accounting purposes. This original system is now considered obsolete. The second version is Extended TACACS, which is an extension to the older TACACS protocol that provides information about protocol translator and router information that can be used in UNIX like systems for auditing trails and accounting files. Extended TACACS is also now considered to be obsolete. TACACS+ is a recent protocol that provides detailed accounting information and flexible administrative control over authentication and authorization processes. TACACS+ is facilitated through Authentication, Authorization and Accounting (AAA) and can be enabled only through AAA commands. A full description of the implementation of TACACS+ can be found in a draft Request For Comment (RFC) 1492. For the purposes of simplicity all three TACACS implementations will be referred to as TACACS in this document, and it should be understood that any derivative of such a system can be substituted for TACACS. PPP is used to carry IP over dial configurations and supports both Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) as methods of password transfer. PPP has been modified to support numerous always-on access technologies including PPP over ATM (PPPoA), PPP over Frame Relay (PPPoF), and PPP over Ethernet (PPPoE).
With the creation of Competitive Local Exchange Carriers (CLECs) it is common to find a company which is delivering telephony over packet based networks and supplying clients with data based services. In addition, if there are two clients in close physical proximity to each other it would be advantageous to connect them to a common access network so that there is a single connection to the CLEC. However, this single connection to the CLEC is only feasible if a stronger user authorization scheme is implemented. Thus, a need exists in the art for an improved user authentication and authorization system.